-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPS scramble recorder #2896
GPS scramble recorder #2896
Conversation
for detection / re-offsetting possibility
We want to replace to avoid accidentally enabling both, or having recorder's interface having to deal with two different lon/lat fields.
Thanks. It should probably be noted in the readme that this will break things like the drawing of recorded GPS tracks on top of a map, as well as calculated distance/etc (because distance depends on latitude). Maybe it's safer to make GPS Scramble actually just record GPS data in its own columns (and disable the in-built GPS). You could then do But the more I think about this the worse an idea I think it is... I mean, the position offsets are on the watch anyway (now in code, but I guess later in a settings file), so anyone could figure out what your GPS traces were if they really cared anyway, and right now with the undocumented options in interface.html this just feel like a trap designed to trip up normal users wanting to use the GPS recorder. Please could we at least have some comments to the extra options in the interface.html that make it clear they are for the GPS Scramble app and shouldn't be enabled otherwise? If you're seriously concerned about data privacy we need something a bit more global - stuff like unread notifications and health history data probably want to be secure too and we really don't want every app developer implementing their own different (and probably insecure) encryption schemes. |
Yes that's a fair point about it messing up the actual GPS entries in the log, I'll move them to another column. I think to find out the source GPS traces, someone would need the original starting coordinates though, right? Otherwise they'd be trying to overlay a trace on various parts of the surface of the earth around where they found the watch, seeing if it would line up with roads etc? But yes, it doesn't hold a candle to actual crypto, but my threat model is a non-techie who's interested in anything they can quickly garner from a discovered watch. If we were to take a more global approach, any computational effort could be offloaded to the firmware and we don't have to worry about maintaining a key in memory across JS reloads. The user would only need to enter a key when their watch is powered on, for example. The only question is how do we handle someone accessing the watch when it's powered on? I'd like to avoid a lockscreen as I really enjoy the accessibility of BangleJS. (Happy to move this conversation back to the forum if preferred) |
Yes, probably best to talk in the forum. I was imagining not actually encrypting what's written to the storage as that seems a bit heavy, but just restricting Bluetooth access to the device (maybe allowing a password/passcode that the app loader/gadgetbridge saved, or even just using Bluetooth's bonding/security in such a way that nobody but you could pair a new device). I guess if someone had access to the watch but it wasn't connected to a phone they might be able to find some data, but that is almost a separate problem - I guess we could add something like "don't unlock watch unless there's a trusted bluetooth connection" |
I like those ideas, shall have a think about it and continue a discussion in the forum |
Will close this for now - I'm leaning towards |
Ok, thanks! Right now I don't believe we prompt for a password on connection when E.setPassword is set, but I guess we could send a |
Sounds like a plan, I'll see what I can do |
Following on from the forum discussion, I've implemented an initial, very simple way of obfuscating GPS data, based only on the user's starting position.
This also includes changes to
recorder
'sinterface.html
for re-originating the GPS data to unobfuscate it (more details in the readme).Depends on / includes changes from espruino/Espruino#2394, which will be properly generated in a separate PR.
Recorder (and this app) deployed on my gh-pages if you want to inspect how the changes work.